chore(deps): update all-dependencies (major) - #38

v5.0.0

Compare Source

Upgrade Guide

🤖 pinact is now AI friendly

v5 is about coding agents. An agent that is asked about pinact, or that hits a pinact error in CI, has until now had to answer from its training data, from the source code, or from whichever version of the website it happened to land on. v5 gives it three things so that it answers from the pinact that is actually installed:

#​1708 An Agent Skill
#​1708 pinact docs: the documentation, embedded in the binary
#​1705 pinact json-schema: the JSON Schema of the configuration file, embedded in the binary

An Agent Skill

gh skill install suzuki-shunsuke/pinact pinact

The skill carries no documentation of its own, deliberately. It is installed separately from the binary, so anything copied into it would go stale, and an agent would confidently describe a flag or an error code of a version that isn't the one on the machine. Instead the skill tells the agent to run pinact docs list and pinact docs show <name> before answering, so the answer always comes from the installed pinact and the skill and the binary can never disagree about a version.

It adds only the few things an agent gets wrong unless it is told: that pinact run edits files and --check is the way to look without touching them, that --update changes which version a workflow uses, and that the exit codes 1 and 2 are findings rather than pinact failing.

pinact docs

$ pinact docs list          # the name and the description of every document, as JSON
$ pinact docs show config   # one document
$ pinact docs show codes/005

The documents are embedded in the binary, so there is nothing to fetch. An agent doesn't need network access to read them, doesn't have to guess which branch or tag of the repository to read, and cannot land on the documentation of a version other than the one it is being asked about. docs list reports a description of every document, written to name the symptoms a reader arrives with, so an agent can pick the one document it needs instead of reading them all.

The README is split into documents so that the binary ships them: --update, --min-age, --no-api, SARIF, --diff-file, and the access token used to exist only in the README, which the binary doesn't ship, and they are exactly the things an agent asks about. pinact docs list now lists 21 documents instead of 12, and the README goes from 431 lines to 169, keeping what someone reads to decide whether to use pinact.

The command is only useful to an agent that knows it exists, and an agent arrives at pinact through one of three places, so all three say so. pinact --help says it in the root command's description, every error pinact reports carries the hint as the help attribute, and pinact -v logs it:

$ pinact -v
pinact version v5.0.0
INF If you are a coding agent, run `pinact docs list` to list the documentation and `pinact docs show <name>` to read it before answering questions about pinact or troubleshooting its errors.

Checking the version is often the only pinact command an agent runs before it starts answering, so without this it never learns that the documentation is there. The hint goes to stderr as a log rather than to stdout, so it doesn't break a script that parses the version, and it is logged at the info level, so --log-level warn silences it. The routine outcomes of pinact run are unaffected: the exit codes 1, 2, and 3 are unchanged, and nothing is logged for them.

pinact json-schema

$ pinact json-schema > pinact.json

The schema is embedded in the binary too, so it is the schema of the configuration that the running version accepts. An agent writing or reviewing a .pinact.yaml can read the exact set of fields, their types, and which ones are required, rather than inferring them from an example it has seen. The copy served from GitHub, which the existing yaml-language-server comments point at, describes whatever main or the pinned tag holds instead.

#​1707 makes that schema worth reading: every field is now described, including version, files[].pattern, ignore_actions[].name, and ignore_actions[].ref, which had no description at all.

Editors such as VSCode use the same schema to complete the configuration file and to warn about invalid settings.

⚠️ Breaking Changes

#​1704 The CLI is built with spf13/cobra instead of urfave/cli

The commands, the flags, and their behavior are unchanged, but a long flag must now be written with two dashes.

# v4
pinact run -check
pinact run -fix=false -no-api
pinact run -diff-file diff.txt

# v5
pinact run --check
pinact run --fix=false --no-api
pinact run --diff-file diff.txt

urfave/cli accepted a long flag with a single dash. cobra's flag parser does not: a single dash introduces short flags, and -c is the short flag of --config, so -check would otherwise be read as --config=heck and pinact would silently look for a configuration file named heck. To prevent that, pinact rejects a single-dash long flag with an error naming the form to use:

$ pinact run -check
unknown flag: -check. Long flags need two dashes since pinact v5: --check

Short flags are unchanged and can still be written with a single dash:

pinact run -u -m 7
pinact run -i "^actions/.*$" -e "^actions/checkout$"
pinact init -g
pinact -c pinact.yaml run

--verify and --sep also keep working, as aliases of --verify-comment and --separator.

The migration fixes two urfave/cli bugs that pinact ran into:

• A workflow file named help could not be passed to pinact run: the argument was taken as a request for the help of run.
• Pressing TAB after a -- ran the command instead of completing it (urfave/cli#1993). Since pinact run fixes files by default, a TAB pressed while typing a pinact run -- command line rewrote the workflow files then and there. cobra completes through a separate hidden command that never reaches the action.

cobra also brings its own completion command, so pinact completion bash|zsh|fish|powershell generates a completion script.

#​1704 The Go module path is now github.com/suzuki-shunsuke/pinact/v5

go install github.com/suzuki-shunsuke/pinact/v5/cmd/pinact@latest

This affects anyone importing pinact as a library, and go install. Installing the CLI from a release asset or via aqua is unaffected.

#​1708 Documents under docs/ are renamed with underscores

docs/why-pinact-not-pin.md becomes docs/why_pinact_not_pin.md, so a link to the old path from outside this repository breaks. The README is also split into documents, so links to the section anchors that moved, such as #update-actions--update, now land on the README rather than on the section.

Fixes

#​1707 Describe every configuration field in the JSON Schema, and correct required

min_age was required by the schema, so every configuration file without it was reported as invalid. That is fixed, and version, ignore_actions[].ref, and rules[].conditions, which pinact does require, are now marked required. The description of files is also no longer truncated at a comma.

Dependency Updates

#​1689 #​1711 Update Go to v1.27.1

#​1681 Update module github.com/suzuki-shunsuke/ghtkn-go-sdk to v0.6.1
#​1713 Update module github.com/google/go-github/v90 to v91
#​1715 Update module golang.org/x/oauth2 to v0.37.0

v4.1.1

Compare Source

Dependency Updates

#​1634 Update Go to v1.26.5

#​1659 Update module github.com/suzuki-shunsuke/ghtkn-go-sdk to v0.5.0
#​1622 Update module github.com/urfave/cli/v3 to v3.10.1
#​1633 Update module github.com/google/go-github/v88 to v89

#​1646 Update dependency sigstore/cosign to v3.1.2
#​1653 Update dependency anchore/syft to v1.49.0
#​1657 Update dependency goreleaser/goreleaser to v2.17.1

v4.1.0

Compare Source

Features

#​1578 Update ghtkn-go-sdk to v0.3.0 for backend and disable device flow support

v4.0.0

Compare Source

⚠️ Breaking Changes

#​1540 Removed the -review option

Output SARIF and pass it to reviewdog. This has been announced previously.

pinact run -format sarif |
  reviewdog -f sarif -name pinact -reporter github-pr-review

#​1540 Always output diff

Even if you specify -diff=false, it is ignored.

#​1540 -diff and -check are now aliases for -fix=false

This simplifies the logic, making it easier to understand and less prone to bugs.

#​1540 -verify is now an alias for --verify-comment

-verify was unclear about what was being verified, so it has been renamed for clarity.
However, -verify is kept as-is to maintain backward compatibility.

#​1458 #​1558 Version comments are now required @​ManuelLerchnerQC

For SHAs without a version comment, pinact automatically adds a version comment (validation error if -fix=false).

$ pinact run test.yaml
test.yaml:1
- - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd
+ - uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2

Specifying a version comment makes it easier to see which version is being used, and makes it easier for tools like Renovate and Dependabot to update.
It also has security implications.
For GitHub Actions versions, you can also specify the SHA of a commit in a fork.
This means it could point to a malicious commit in a fork.
If you specify only the SHA without a version comment, you cannot tell whether it is the SHA of a commit in a fork.
By requiring version comments, you can verify that the version comment matches the SHA using the --verify-comment option.
Even if a fake version comment is added to a fork's SHA, it can be detected by --verify-comment.
An attacker could also create a tag pointing to a fork's SHA, but creating a tag requires write permission, which raises the bar for attacks, so this can be said to improve security.
Of course, this is only meaningful if you verify with --verify-comment, so it is recommended to run pinact with --verify-comment in CI.

Features

#​1540 -no-api: support for offline validation
#​1540 You can now check whether the version being used satisfies min age, not just newer versions
#​1540 More flexible min age support via rules
#​1540 #​1542 #​1543 Support for a global configuration file
#​1435 Automatic correction of version comments via -verify-comment @​ManuelLerchnerQC
#​1547 #​1552 #​1557 #​1562 -diff-file: limit pinact's targets to only the changed lines

-no-api: support for offline validation

If you just want to check whether something is pinned, you don't really need to use the GitHub API, but previously the GitHub API was called.
With the -no-api option, you can validate without calling the GitHub API.
However, since API calls are currently essential for fixing code (this may change in the future if caching is supported), you need to specify either -fix=false or -format sarif.
Implicitly treating it as -fix=false could cause behavior to change and become a breaking change when caching is supported, so it must currently be specified explicitly.

You can now check whether the version being used satisfies min age, not just newer versions

For example, you can run it in CI against modified lines to check whether any dangerous versions that do not satisfy min age are being used.
This is not checked by default, but is checked when you run pinact run --verify-min-age or pinact run -min-age <min age>.

More flexible min age support via rules

min age can now be configured in the configuration file.
Additionally, by using rules, you can apply settings such as min age to specific actions.

min_age:
  value: 7 # default setting
rules:
  # Allow latest for suzuki-shunsuke's actions
  - ignore: true
    conditions:
      - expr: |
          ActionRepoOwner == "suzuki-shunsuke" && ActionVersion == "latest"
  # Set min age to 0 for actions/checkout
  - min_age: 0
    conditions:
      - expr: |
          ActionRepoFullName == "actions/checkout"

For rules, conditions are evaluated per rule, and the settings are applied if matched.
You can write multiple conditions, and the settings are applied if any one of the conditions matches.
expr follows https://expr-lang.org/docs/language-definition. Please read the documentation for details.
The settings of rules listed later in rules take precedence.

Support for a global configuration file

[!WARNING]
If you have set the PINACT_MIN_AGE environment variable in ~/.bashrc, ~/.zshrc, etc., it is recommended to remove it and use a global configuration file instead.
PINACT_MIN_AGE takes precedence over the configuration file, so it overrides the project's settings.
On the other hand, global settings are merged with lower priority than the project's settings.
If you want to enforce the setting, PINACT_MIN_AGE is suitable, but for default settings, a global configuration file is more appropriate.
Note also that environment variables do not allow flexible settings like rules.

A global configuration file is now supported.
The file path is searched in the following order of priority:

1. $PINACT_GLOBAL_CONFIG
2. ${XDG_CONFIG_HOME}/pinact/pinact.yaml
3. ${HOME}/.config/pinact/pinact.yaml

On Windows:

1. $PINACT_GLOBAL_CONFIG
2. %APPDATA%\pinact\pinact.yaml

rules are prepended before the rules in the project configuration file.
So project settings take precedence over global settings.

Automatic correction of version comments via -verify-comment

If the SHA and the version comment do not match, the version comment is automatically corrected to match the SHA.
Previously, it would just return an error, but now it is automatically corrected.

-diff-file: limit pinact's targets to only the changed lines

If you specify a file in Unified Diff Format via -diff-file, you can limit pinact's targets to only the changed lines.
By passing the PR's diff file in PR CI, you can reduce unnecessary API calls and prevent corrections or errors from code unrelated to the PR's changes.
This makes it easier to introduce pinact via Required Workflow across an entire GitHub Organization of a large development organization.
To improve the overall health of a development organization, it is desirable to introduce pinact via Required Workflow.
However, if you suddenly introduce pinact as a Required Workflow in an Organization that has a lot of originally unpinned code, errors and corrections unrelated to the PR's changes will occur everywhere, causing confusion.
When errors occur in places unrelated to the PR's changes, the PR author thinks "what is this error?", "wait, do I have to fix this? It's unrelated to this PR so I want to split the PR, but creating a PR is a hassle."
It is also possible that the same error occurs in multiple PRs, and each one independently performs redundant fixing work.
Inquiries about errors come in from various teams, generating unnecessary costs.
If you try to fix everything before introducing the Required Workflow, it takes time to introduce, and during that time the bad situation continues where new unpinned code keeps increasing.

On the other hand, if you can fix and validate only the lines changed in a PR, the PR author can more easily accept making the fix, and there is no need to split the PR.
However, this alone does not pin existing code, so in parallel with this, you still need to run pinact against each repository and create PRs.

How do you generate the file specified by -diff-file? You can easily generate it using the action https://github.com/suzuki-shunsuke/pr-unified-diff-action.

- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
  with:
    persist-credentials: false
- uses: suzuki-shunsuke/pr-unified-diff-action@c932c1df5f577028d8ca05d2d3c0c059072d8821 # v0.0.1
  id: diff
- uses: suzuki-shunsuke/pinact-action@896d595f299e71d65b9d28349d6956abe144390a # v3.0.0
  with:
    diff_file: ${{ steps.diff.outputs.diff_path }}

v3.10.1

Compare Source

🐛 Bug Fixes

#​1535 pin uses lines with multiple spaces after the YAML list dash

v3.10.0

Compare Source

Features

#​1530 Support pinning branches to latest stable tags by the --branch-to-tag option

The default behabiour isn't changed.
By default, pinact doesn't pin branches such as main or master.
If you want to pin specific branches, you can use the --branch-to-tag option.

e.g.

pinact run --branch-to-tag '^main$' --branch-to-tag '^release/.*$'

v3.9.2

Compare Source

Fixes

#​1493 Preserve original line endings when updating workflows

v3.9.1

Compare Source

v3.9.0

Compare Source

Features

#​1365 Make version separator configurable via configuration file @​ReenigneArcher
#​1372 Make version separator configurable via command line option and environment variable

🐛 Bug Fixes

#​1359 Fix a bug that -log-color doesn't work

Others

• docs: fix readme for ignore_actions[].ref by @​nasa9084 in #​1323
• docs: fix readme for correct GHES_API_URL by @​maruloop in #​1324
• docs(INSTALL): add mise alternate installation documentation by @​jylenhof in #​1331

v12.8.1: pnpm 12.8.1

Compare Source

pnpm 12.8.1 fixes pnpm install --frozen-lockfile rejecting lockfiles with injected workspace packages that have peers, restores the executable bit on files of local directory dependencies, makes pnpm dedupe converge, and uses less CPU on many-core machines.

Patch Changes

• pnpm install --frozen-lockfile no longer rejects a freshly generated lockfile when an injected workspace package has peer dependencies #​16332.

• Executable files in a file: directory dependency or an injected workspace package keep their executable bit again. Since 12.8.0, pnpm installed these files without the permissions they have in their project.

• pnpm dedupe now reaches a stable lockfile when a package's peer suffix is long enough to be hashed. Before, each run could switch that package's key between the hashed and the spelled-out suffix, so pnpm dedupe --check always failed #​16331.

• pnpm install --frozen-lockfile, the default in CI, now uses less CPU on machines with more than 8 cores. Warm installs on many-core Windows machines got up to 10% faster. Frozen installs now link with at most 16 worker threads.

• verifyDepsBeforeRun no longer reports dependencies as outdated after a filtered install just because pnpm-lock.yaml has a newer modification time. It checks the lockfile against the packages that install put in place. Before, pnpm run reinstalled the whole workspace with lifecycle scripts on, for example after a Docker COPY brought in a lockfile with a newer mtime #​16322.

  After a filtered install, verifyDepsBeforeRun now also checks that the install put the selected projects' dependencies in place. A node_modules directory alone no longer counts as proof.

• pnpm run and pnpm exec no longer install a project that has never been installed and has nothing to install. Such a project declares no dependencies, no peer dependencies that autoInstallPeers would fetch, and no install lifecycle scripts. The command now runs without writing node_modules or pnpm-lock.yaml #​16313.

• pnpm update -g --latest now upgrades globally installed packages beyond their saved version ranges #​16320.

Platinum Sponsors

Gold Sponsors

v12.8.0: pnpm 12.8

Compare Source

pnpm 12.8.0 warns when pnpm pack or pnpm publish would ship a .env file that files does not list, installs sharedWorkspaceLockfile: false workspaces concurrently, applies every setting passed as --config.<name>=<value>, and no longer leaves the Windows terminal stuck after Ctrl+C in a script.

Minor Changes

• pnpm pack and pnpm publish now warn when the tarball includes a .env or .env.* file that the files field of package.json does not list. Templates such as .env.example are not reported. List the file in files to publish it on purpose, or exclude it in .npmignore or .gitignore #​7826.

• pnpm pack now honors --silent, --reporter=silent, and --loglevel=silent to hide the tarball contents and summary. With --json, lifecycle script output and the final JSON output remain visible #​10297.

Patch Changes

Installing packages

• Installing through a pnpr server now records the pnpmfile checksum in the lockfile, so a later pnpm install --frozen-lockfile accepts that lockfile #​14460. A frozen install through the pnpr server now fails if the pnpmfile changed. If the pnpmfile defines a readPackage, afterAllResolved or preResolution hook or custom resolvers, pnpm resolves dependencies locally and prints a warning that the pnpr server was not used.

  Installing through a pnpr server also links a workspace project at the directory its publishConfig.directory names. A server that does not forward the setting makes the install fail with ERR_PNPM_PNPR_PUBLISH_DIRECTORY_MISMATCH, so pnpm never writes a lockfile that points at the wrong directory. The server rejects a publishConfig.directory that points outside its project.

• Installing a git-hosted dependency that has to be built no longer fails when that dependency's own dependencies have build scripts nobody approved. pnpm skips those builds while preparing the dependency, as it does without strictDepBuilds #​9764.

• A git-hosted dependency that is a pnpm workspace with no committed lockfile is now detected as a pnpm project #​14011.

• pnpm install --dev and pnpm fetch --dev now install the optional dependencies of devDependencies, such as the platform binaries of Biome and oxlint. The project's own optionalDependencies are still skipped #​9678.

• pnpm install --offline and pnpm add --offline now resolve a version range to the newest matching version whose tarball is already in the store. They used to pick the newest version in the cached metadata and fail with ERR_PNPM_NO_OFFLINE_TARBALL when its tarball was missing #​10715.

• If an offline install fails because the registry metadata cache uses the layout from before pnpm 11.27 and 12.4, the error now names the older mirror on disk and explains that one online install repopulates the cache. The error also carries the ERR_PNPM_NO_OFFLINE_META code. pnpm cache prune --help now says that pnpm 11.26 and earlier, and pnpm 12.3 and earlier, depend on the directories it removes #​15656.

• Running pnpm install now refreshes dependencies when a package declared with a local file: directory changes its dependencies #​4623.

• A repeat pnpm install now keeps its fast up-to-date check when an override replaces a declared local file: dependency #​12892.

• pnpm install now removes an optional dependency from node_modules if its install script fails. Code that checks whether the package is installed no longer finds a package that cannot load #​8756.

• With nodeLinker: hoisted, pnpm install now restores a workspace project's node_modules after it was deleted. Before, the install printed "Already up to date" and left the project without the dependencies nested under it. On Windows, the install also no longer fails with "Access is denied" when another project's copy of a shared dependency links to the deleted directory.

• Under nodeLinker: hoisted, pnpm install now clears orphaned package directories that an interrupted or failed install leaves in a project's node_modules. A directory recorded by the previous install is removed, while an unrecorded directory is moved to node_modules/.ignored. A copy already in .ignored is never overwritten #​13676.

• Concurrent installs no longer fail when they replace the same stale hoisted dependency link. Virtual store cleanup now keeps the temporary lockfiles that concurrent installs write.

Resolving and linking dependencies

• pnpm install no longer aborts on a failed allocation of many gigabytes when peer dependency ranges combine overlapping || alternatives #​15867.

• pnpm install no longer fails when a package from the registry declares a file: dependency on a directory inside itself, such as "@types/css-tree": "file:./typings/css-tree". pnpm links that dependency to the directory inside the package, as npm and Yarn do. The lockfile records it as link:<root>/typings/css-tree #​9141.

• An npm: alias written by overrides now stays in place when a change elsewhere makes pnpm re-resolve the aliased dependency. Before, pnpm could look up the alias name at the aliased version, which failed with ERR_PNPM_NO_MATCHING_VERSION or locked an unrelated package #​16309.

• A peer dependency no longer resolves to two different versions for one package. This happened when the package peer-depends on another package and on one of that package's peers, and it is installed deeper than a direct dependency of the package that provides them #​12098.

• An optional peer dependency is no longer resolved from another workspace project's package when the project provides one of that package's own peers at a version it rejects. This avoids bogus unmet peer errors #​13989.

• pnpm dedupe no longer changes the lockfile on every run when a nested peer dependency is provided through an npm alias #​15709.

• With resolutionMode: time-based and minimumReleaseAge both set, pnpm install no longer reports a subdependency as too new when only the time-based cutoff excludes it. Such subdependencies used to fail a strict install with ERR_PNPM_NO_MATURE_MATCHING_VERSION, or were added to minimumReleaseAgeExclude #​13569. A transitive dependency that has no matching version published before the time-based cutoff now resolves to the lowest matching version allowed by minimumReleaseAge. pnpm picks a version younger than minimumReleaseAge only if no older version matches #​16298.

• pnpm install retries registry metadata fetches that fail with a timeout, a dropped connection, or an interrupted response body before it applies trustPolicy or minimumReleaseAge. A transient fetch failure is not reported as TRUST_DOWNGRADE or MINIMUM_RELEASE_AGE_VIOLATION #​12031.

• pnpm's built-in package compatibility database no longer applies to a project's own manifest. A project named like a published package, such as vue-loader, no longer gains dependencies on pnpm install or pnpm update. User-configured packageExtensions still apply to project manifests #​11700.

• Packages in an external virtualStoreDir can resolve the project's direct dependencies selected by hoistPattern. Run pnpm install --force to repair an existing installation #​5652.

• pnpm install now links the executables of auto-installed peer dependencies into the workspace root's node_modules/.bin, including after a frozen-lockfile reinstall #​8511.

Lockfiles and frozen installs

• pnpm install --frozen-lockfile now works on a detached HEAD when gitBranchLockfile is enabled. The install reads the lockfiles of the local and remote-tracking branches that contain the checked-out commit. It still writes the shared pnpm-lock.yaml #​7672.

• pnpm install --frozen-lockfile now accepts a lockfile that has no importer entry for a workspace package without dependencies. Such a package added after the lockfile was written made the install fail with ERR_PNPM_PACKAGE_MANAGER_NO_IMPORTER #​15875.

• pnpm install now fails with ERR_PNPM_LOCKFILE_MISSING_DEPENDENCY when an importer references a dependency version that has no snapshot entry. Before, the install succeeded and left a node_modules symlink pointing at a missing virtual-store directory #​14764.

• pnpm install on CI now fails on an outdated lockfile when preferFrozenLockfile is explicitly set to true. Setting it to true used to let CI update the lockfile #​9072.

• With gitBranchLockfile enabled, each emoji or other character outside the Basic Multilingual Plane in a branch name now becomes !! in the lockfile name. Before, each such character became one !.

Workspaces and filtering

• pnpm install in a workspace with sharedWorkspaceLockfile: false now installs projects concurrently, up to workspaceConcurrency at a time #​14480. A project is resolved, fetched, and written to its virtual store without waiting for the workspace projects it depends on. It waits for them only before it links its dependencies and runs its lifecycle scripts, so its scripts still run after theirs. A project with a preinstall or pnpm:devPreinstall script, or with an injected or file: workspace dependency, waits for its workspace dependencies before it starts.

  The installs of the projects also share their package metadata, lockfile verification, and store caches, so they use less CPU and memory when several projects depend on the same packages. An install with a pnpmfile no longer starts an extra Node.js process when the pnpmfile has no preResolution hook.

• With enableGlobalVirtualStore and sharedWorkspaceLockfile: false, each project now keeps its current lockfile and its hidden hoisted dependencies in its own node_modules/.pnpm. Before, every project wrote them to the workspace root's node_modules/.pnpm, so each repeat install treated the other projects' packages as its own and relinked them #​14480.

• pnpm rebuild, pnpm approve-builds, and pnpm ignored-builds now work on the current project's node_modules when they run inside a project of a workspace with sharedWorkspaceLockfile: false. They used to read the workspace root's node_modules, so pnpm rebuild did not rebuild the project's dependencies and created a second virtual store at the workspace root #​9402.

• pnpm install no longer creates a node_modules symlink inside the publishConfig.directory of a workspace package linked with linkDirectory. A build tool that cleaned its output directory through that symlink deleted the files of the package's dependencies. pnpm install also removes a symlink that an earlier install left there #​16226. It also no longer fails with ERR_PNPM_CMD_SHIM_RESOLVE_PATH when such a package has a bin field and its publishConfig.directory does not exist yet.

• pnpm install no longer fails for an injected workspace dependency whose package publishes from a publishConfig.directory that its own prepare script builds. The injected copy now picks up that directory once prepare finishes building it. pnpm install --frozen-lockfile no longer reports the dependency as outdated while the directory has not been built yet #​7811.

• An in-place edit to the source of an injected workspace package now shows up in its injected copy, unless a build writes to that package or packageImportMethod is set. pnpm hardlinks such packages under the default import method #​4410. Scripts listed in syncInjectedDepsAfterScripts now update injected dependencies while they run, so a watcher on the injected package, such as a dev server, sees each change before the script exits.

• With sharedWorkspaceLockfile: false, an injected workspace package that has lifecycle scripts is now hard linked into the projects that depend on it. Before, pnpm left a plain copy, so later edits to the package did not reach those projects #​9828.

• injectWorkspacePackages now hard links a workspace dependency declared with a relative path, such as workspace:../foo, the same way it already does for workspace:* #​10446.

• Workspace discovery prunes dot-prefixed directories, so a packages pattern such as ** no longer matches projects inside .cache and other hidden directories #​16250.

• pnpm import in a workspace now keeps the versions pinned by a yarn.lock inside a workspace project #​4385.

Store and caches

• Files imported from the store now follow the umask of the install that writes them. Installing with a umask of 077 no longer leaves imported files readable by the group and others #​3807.

• pnpm install keeps the owner, group, and mode of files already in a shared store, including index.db. New store files and directories inherit the store directory's group-write bit. When that directory is setgid, new files inherit its group. pnpm does not change a file's owner or group #​12765.

• When pnpm install repairs a store file that was modified through a hard link in node_modules, the repair now keeps the file's inode on Linux and macOS, so hard-linked copies in other projects are healed at the same time. On Windows the repair still replaces the file, so other projects are healed on their next install #​3445.

• pnpm install now reports a full store at once when writing package files fails. It no longer retries the tarball #​8581.

• pnpm now warns when it cannot hard link packages from an existing store in the pnpm home directory and falls back to a store on the project's filesystem. This can happen when the project is on another filesystem, such as a bind-mounted workspace in a container. The warning names both stores and suggests setting storeDir #​14505.

• The side-effects cache now restores the symlinks that a build script creates inside a package. A warm install used to replace each of them with a copy of its target #​12859.

  After upgrading, every package with a build script is built once more.

• The global virtual store and the side-effects cache now key built packages by the Node.js version that the root project's devEngines.runtime or engines.runtime pins. That is the Node.js their build scripts run with. A dependency that declares its own engines.runtime no longer changes the key for every other package.

• With enableGlobalVirtualStore, an install into a fresh node_modules no longer runs the build scripts of a dependency whose global virtual store slot an earlier install already built. pnpm rebuild still runs them #​14480.

• Concurrent installs that share a global virtual store now run a package's build in its shared slot one at a time. A failed build leaves the slot in place and marks it for the next install to rebuild #​15568.

• A warm pnpm install reuses on-disk package metadata for five minutes when the registry does not send an ETag. Registries that send an ETag, including the public npm registry, still revalidate with a conditional request. pnpm update still fetches current metadata #​13976.

• pnpm no longer revalidates cached registry metadata when the registry sends Cache-Control: max-age=0, no-cache, or no-store. It downloads the metadata again, so a version newly published to such a registry is visible on the next install #​13487.

• pnpm install honors Cache-Control for dependencies named with an http: or https: tarball URL. A fresh response is taken from the store with no request, and a stale one is revalidated with If-None-Match #​15648.

Patched dependencies

• pnpm install now repairs a pnpm-lock.yaml whose (patch_hash=<hash>) dependency paths disagree with its patchedDependencies map, including paths that lack the hash their patch calls for. Before, pnpm accepted such a lockfile as up to date and kept the old patched files. pnpm install --frozen-lockfile now fails on such a lockfile with ERR_PNPM_INCONSISTENT_PATCH_HASH. It fails with ERR_PNPM_UNCHECKABLE_PATCH_HASH when a patch hash in the lockfile is malformed, or when the lockfile lacks the package version or patch entry that the check needs #​15336.

• pnpm install with nodeLinker: hoisted now applies a patch once to each copy of a patched dependency in a workspace. Before, a copy that several workspace projects shared could receive the patch twice and end up with the patched content duplicated #​7565.

• pnpm install and pnpm fetch now fail with ERR_PNPM_PATCH_NOT_FOUND when a patch file listed in patchedDependencies does not exist #​5268.

• engineStrict now checks the patched package.json when a patchedDependencies entry changes engines. A patch that relaxes engines.node no longer fails the install against the published range #​9603.

• pnpm patch now applies the existing patch file to the edit directory of a git-hosted dependency, as it already does for packages from the registry #​9699.

Adding, updating, and removing dependencies

• pnpm add <dir> now warns when the added directory declares peer dependencies, as pnpm link does. The directory is saved as a link: dependency, and its peers are not resolved from the project that adds it. Use the file: protocol to have them resolved #​5523.

• pnpm add --save-types no longer adds a @types/* package whose resolved version is deprecated. DefinitelyTyped publishes such stubs for packages that ship their own types, such as @types/typescript for typescript #​15636.

• pnpm version, pnpm add, and pnpm pkg set keep JSON5 style when they update package.json5. ASCII identifier keys stay unquoted, strings keep JSON5 quotes, and indented files keep trailing commas #​15717.

Running scripts and commands

• pnpm run and pnpm exec no longer install dependencies automatically when the root package.json still keeps overrides, packageExtensions, patchedDependencies, or ignoredOptionalDependencies in its pnpm field. pnpm no longer reads that field, so the install rewrote the lockfile without those settings. The command now fails and asks to move the settings to pnpm-workspace.yaml #​16278.

• When verifyDepsBeforeRun triggers an install before a filtered pnpm run or pnpm exec, pnpm now installs only the selected projects and their dependencies. A later filtered command also installs a selected project that an earlier filtered install skipped #​11865.

• pnpm -r run /regexp/ now honors the tasks dependsOn declared for each script the selector matches, like running the script by name does. Matched scripts that depend on each other run in order. Each matched script runs once #​15596.

• pnpm run exits with the code of a script that handles Ctrl+C and shuts down. A script that finished cleanly is not reported as a lifecycle failure. The commands after it in the same script still run #​9945.

• pnpm no longer hangs after a lifecycle script exits while a process it started in the background keeps the script's output open. pnpm stops reading that output one second after the script exits #​5730.

• pnpm run and lifecycle scripts use the configured scriptShell, including Git Bash on Windows, when shellEmulator is also enabled. shellEmulator still runs scripts when scriptShell is not set. Extra arguments passed to pnpm run are quoted for the shell that runs the script, so a Windows path stays intact #​14719.

• With enableGlobalVirtualStore, dependency build scripts now see the workspace root's node_modules/.bin, as they do with a local virtual store. A postinstall script that runs node finds the Node.js installed by devEngines.runtime and no longer fails with "command not found" on machines without a system Node.js #​15652. Dependency build scripts also see the bins of privately hoisted dependencies.

• Dependency install scripts now find the node-gyp bundled with pnpm when pnpm runs through a symlink, such as node_modules/.bin/pnpm or the pnpm that npm install -g pnpm links. They used to fail with node-gyp: command not found on macOS #​15694.

• pnpm run and lifecycle scripts now set npm_config_node_gyp to the bundled node-gyp entry point. Tools that read the variable resolve the same node-gyp pnpm builds with. An npm_config_node_gyp value the environment already sets is kept as is #​16270.

• Scripts now see the npm_command environment variable that npm sets. It holds run-script when the command runs a script, and the command's own name otherwise #​16265.

• Commands run from a POSIX shell through a dependency's own node_modules/.bin, such as node_modules/vite/node_modules/.bin/esbuild, no longer fail with MODULE_NOT_FOUND #​10189.

• pnpx --version and `pnpm d

❗ Important

✂ PR body was truncated to here.